Vectorize remove_copy and unique_copy#5355
Merged
StephanTLavavej merged 41 commits intomicrosoft:mainfrom Apr 22, 2025
Merged
Conversation
Less error prone, especially if implementing _copy someday
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as off-topic.
This comment was marked as off-topic.
# Conflicts: # benchmarks/src/unique.cpp # stl/inc/algorithm # stl/src/vector_algorithms.cpp
StephanTLavavej
approved these changes
Apr 22, 2025
Member
|
Thanks! 😻 I pushed fixes for significant bugs in the "can compare equal to value type" codepaths, and expanded the test coverage (auditing all existing codepaths, and verifying that the new tests caught the bugs). Please double-check. 5950X results:
|
Contributor
Author
All looks good. |
Member
|
/azp run STL-ASan-CI |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Member
|
I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed. |
Member
|
I resolved a trivial adjacent-add conflict with #5352 in |
Member
|
Thanks for these unique speedups, removing all that execution time! 😹 🚀 🤪 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
⚙️ The optimization
remove_copyandunique_copyare different from their non-_copycounterparts in that they don't have room they are allowed to overwrite. This means we can't directly store results from vector registers.The previous attempt #5062 tried to use masked stores to bypass that limitation. Unfortunately, this doesn't perform well for some CPUs. Also the minimum granularity of AVX2 masked store is 32 bits, so it would not work for smaller elements.
This time, temporary storage comes to rescue. The algorithms already use some additional memory (the tables), so why wouldn't it use a bit more. I arbitrarily picked 512 bytes, should be not too much. Each time the temporary buffer is full, it can be copied to the destination with
memcpy, it should be fast enough for this buffer size.🚫 No
findbeforeremove_copyIn #4987, it was explained that doing
findbeforeremoveis good for both correctness and performance. Originally it was in vectorization code, but during the review @StephanTLavavej observed that it is done in the headers already (#4987 (comment)).For
remove_copyit is not necessary for correctness, and may be harmful for performance.findwould needcopyin addition, this will be double pass on the input, which can make the performance worse for large input and memry-bound situation.We may have special handling of the range before the first match in vectorization code, this is another story, and it would not be harmful, but I'm not doing this in the current PR. Maybe later.
So, as we have not called
find, and so have not checked if value type can even match iterator value type, we need this_Could_compare_equal_to_value_typecheck here.✅ Test coverage
Shared with non-
_copycounterparts to save total tests run time and some lines of code, at the expense with otherwise unnecessary coupling.We check both modified and unmodified destination parts, to make sure unmodified indeed didn't modify.
⏱️ Benchmark results
🥇 Results interpretation
Good improvement!
Not as good as for non-
_copycounterparts though, asmemcpytakes some noticeable time.The usual codegen gremlins that cause results variation are observed for non-vectorized tight loops. I've marked the most notorious one with clown. I can't explain that anomality.